Skip to main content
Version: current

Quality of Service

This document describes Quality of Service (QoS) implementation in RouterOS for devices equipped with Marvell Prestera switch chips.

QoS is a collection of features in network switches that allows network administrators to prioritize traffic and allocate network resources to ensure that critical data flows smoothly with low latency.

The primary function of QoS in a network switch is to manage traffic in a way that meets the specific requirements of different types of network applications. For example, voice and video data require low latency and minimal packet loss to ensure high-quality communication, while file transfers and other data applications can tolerate higher levels of latency and packet loss.

QoS works by identifying the type of traffic flowing through the switch and assigning it a priority level based on its requirements. The switch then uses this information to modify packet headers and prioritize traffic flow, ensuring that higher-priority traffic receives preferential treatment over lower-priority traffic.

RouterOS v7.15 or later is required to support all QoS features:

  1. QoS Marking. QoS profile matching by ingress packet header, then egress header modification according to the assigned QoS profile.
  2. QoS Enforcement. Avoid or resolve congestion based on the assigned QoS profile and traffic shaping.
  3. QoS Policy. Assign QoS profiles via ACL rules.
  4. Active Queue Management: WRED (Weighted Random Early Detection), ECN notification and processing, PFC (Priority-based Flow Control).
  5. Traffic shaping.

QoS Changes in RouterOS v7.23​

RouterOS v7.23 introduces significant changes to Quality of Service (QoS) offloading. These changes simplify the configuration process and add support for "lossless" traffic classes. Although hardware resources are finite, active queue management using ECN and/or PFC can prevent packet loss when all connected devices support these features and are properly configured. Previous RouterOS versions already supported ECN and PFC, but v7.23 streamlines how you set them up.

info

Not all devices support lossless traffic. Check the QoS Device Support table.

Configuration Change Summary​

  • QoS Settings: most changes were set to "auto" by default, allowing RouterOS to pick the best known settings for the setup.
  • QoS Settings: added lossless-traffic-class and lossless-buffers, allowing explicit specification of lossless traffic and the reservation of queue resources for it. The user can leave those fields as "auto" as well.
  • QoS Monitor: displays the shared pool usage for lossy and lossless separately.
  • Tx Queue: removed shared pool index. RouterOS automatically selects the shared pool based on the traffic type (lossy or lossless).
  • QoS Profile: added automapping to the specified PCP and DSCP values (enabled by default). For example, adding a QoS profile with DSCP=46 automatically applies the profile to traffic received from trusted ports.

QoS Terminology​

This section defines the key terms and abbreviations used throughout this documentation:

  • QoS - Quality of Service, a collection of features that allows network administrators to prioritize traffic and allocate network resources.
  • ACL - Access Control List, a set of switch rules used to filter network traffic based on specified criteria.
  • AQM - Active Queue Management, a congestion control mechanism that manages traffic flow by dropping or marking packets before queue overflow occurs.
  • DSCP - Differentiated Services Code Point, a 6-bit field in the IP header used to prioritize network traffic.
  • ECN - Explicit Congestion Notification, a mechanism that allows routers to signal congestion to endpoints devices without dropping packets.
  • ETS - Enhanced Transmission Selection, a traffic scheduling method that uses weighted round-robin to allocate bandwidth among multiple queues groups.
  • PCP - Priority Code Point, a 3-bit field in the VLAN header used to prioritize traffic within a VLAN.
  • PFC - Priority-based Flow Control (IEEE 802.1Qbb), a flow control mechanism that pauses traffic on specific priority queues to prevent packet loss.
  • RoCE - RDMA over Converged Ethernet, a protocol that enables remote direct memory access over Ethernet networks.
  • WRED - Weighted Random Early Detection, a congestion avoidance mechanism that randomly drops packets as a queue approaches capacity.
  • /in/eth/sw/ - A CLI shortcut for /interface/ethernet/switch/.

QoS Enhancements in new generation Marvell Prestera Switch Chips​

MikroTik devices with new generation Marvell Prestera switch chips (e.g. CRS8xx series running the switch-marvell package offer a new approach in QoS enforcement. Previous models required making a tradeoff between guaranteed and shared Tx queue buffers. By increasing the shared buffer percentage, the device can absorb larger traffic bursts, but at the same time, one congested port can occupy all shared buffers, limiting the QoS capabilities of other ports. Using the new generation switch chips enables the best of both worlds by introducing Dynamic Buffers. A switch chip dynamically adjusts port and queue buffer limits based on the current congestion level. If there is no congestion within the device, a single port can absorb a large burst of traffic, preventing packet loss. When the Tx queue size increases across multiple ports, the device reduces per-port and per-queue limits, enforcing fair use of shared resources while ensuring enough buffers for non-congested queues to continue forwarding traffic. The entire process is automated, requiring zero configuration from the user.

Another improvement in the new generation Marvell Prestera switch chips is eliminating the shortage of enqueued packet descriptors for storing control data. The previous generation devices had Packet Cap and Use stats. When a device received a burst of small packets, it could start tail-dropping packets due to hitting Packet Cap, even though it had enough queue buffers to store the payload. The new generation devices ensure there is always enough memory to store control data, leaving the Dynamic Buffer size as the only limiting factor. That's why there are no Packet Cap/Use stats in the new generation devices.

New generation devices require QoS HW Offloading to be enabled at all times (qos-hw-offloading=yes). RouterOS ignores user requests to disable it while keeping the field for backward compatibility.

QoS Device Support​

Switch ChipModelsQoS ProfilesQoS MapsTx ManagersWREDECNPFCLossless BuffersDynamic BuffersPort/Queue Usage Stats
98DX3236CRS305-1G-4S+IN
CRS326-24G-2S+ (RM/IN)
CRS328-24P-4S+RM
CRS328-4C-20S-4S+RM		12818Current values
98DX226SCRS305-1G-4S+OUT (FiberBox Plus)
CRS310-1G-5S-4S+ (netFiber 9/IN)
CRS310-8G+2S+IN
CRS318-16P-2S+OUT (netPower 16P)
CRS320-8P-8B-4S+RM
CRS418-8P-8G-2S+RM
CRS418-8P-8G-2S+5axQ2axQ-RM		12818Current values
98DX224SCRS318-1Fi-15Fr-2S-OUT (netPower 15FR)12818Current values
98DX2528CRS304-4XG-IN12818Current values
98DX8525CCR2216-1G-12XS-2XQ
CRS518-16XS-2XQ-RM		10241215✔✔✔✔Max fill 1
98DX4310CRS504-4XQ (IN/OUT)
CRS510-8XS-2XQ-IN
RDS2216-2XG-4S+4XS-2XQ		10241215✔✔✔✔Max fill 1
98DX8208CRS309-1G-8S+IN10241215✔✔✔✔Current values 2
98DX8212CRS312-4C+8XG-RM10241215✔✔✔✔Current values 2
98DX8216CRS317-1G-16S+RM10241215✔✔✔✔Current values 2
98DX8332CRS326-24S+2Q+RM
CRS326-4C+20G+2Q+RM		10241215✔✔✔✔Current values 2
98DX3257CRS354-48G-4S+2Q+RM
CRS354-48P-4S+2Q+RM		10241215✔✔✔✔Current values 2
98DX3255CCR2116-12G-4S+10241215✔✔✔✔Current values 2
98CX8410CRS520-4XS-16XQ-RM10241215✔✔✔✔Unavailable 3
98DX7335CRS812-8DS-2DQ-2DDQ-RM
CRS804-4DDQ-hRM		10241215✔✔✔✔✔Current values + Max fill

1 The device gathers max queue fill statistics instead of displaying the current usage values. Use the reset-counters command to clear those stats.
2 Due to hardware limitations, some switch chip models may experience temporary traffic flow disruption while reading or polling QoS port/queue usage data.
3 Usage data for individual queues on a port is unavailable; only the aggregate total usage for the entire physical port can be accessed.

Applications and Usage Examples​

Basic Configuration Example​

This example demonstrates how to configure a single QoS level for VoIP (IP Telephony) on top of the standard Best Effort class. The configuration uses a CRS326-24G-2S+ device with the following setup:

  • All ports are bridged and use vlan-filtering;
  • sfp-sfpplus1 serves as a VLAN trunk connected to another switch;
  • ether1 through ether9 are dedicated ports for IP phones;
  • ether10 through ether24 are standard ports for host connection.

First, define a QoS profile. This profile specifies the DSCP and PCP values that will be applied to forwarded packets on egress:

/interface/ethernet/switch/qos/profile
add dscp=46 name=voip pcp=5 traffic-class=5

Next, assign the VoIP QoS profile to the dedicated ports for IP phones. This applies the profile to ingress traffic on these ports. All other Ethernet ports will use the default profile (where dscp=0 and pcp=0):

/interface/ethernet/switch/qos/port
set ether1 profile=voip
set ether2 profile=voip
set ether3 profile=voip
set ether4 profile=voip
set ether5 profile=voip
set ether6 profile=voip
set ether7 profile=voip
set ether8 profile=voip
set ether9 profile=voip

The trunk port receives both types of QoS traffic. To differentiate between them, enable trust-l3 and trust-l2:

/interface/ethernet/switch/qos/port
set sfp-sfpplus1 trust-l3=trust trust-l2=trust

Note: If you are running RouterOS version 7.23 or later, the VLAN priority and IP DSCP mapping is created automatically, so this step is not required. If you are using an earlier RouterOS version, you must manually create the VLAN priority and IP DSCP mapping with the QoS profile:

/interface/ethernet/switch/qos/map/ip
add dscp=46 profile=voip

/interface/ethernet/switch/qos/map/vlan
add pcp=5 profile=voip

Finally, enable QoS hardware offloading for the above settings to take effect:

/interface/ethernet/switch
set switch1 qos-hw-offloading=yes

You can verify the port QoS settings using the print command:

[admin@MikroTik] /interface/ethernet/switch/qos/port/print
Column: NAME, SWITCH, PROFILE, MAP, TRUST-L2, TRUST-L3
 # NAME          SWITCH   PROFILE  MAP      TRUST-L2  TRUST-L3  TX-MANAGER
 0 ether1        switch1  voip     default  ignore    ignore    default
 1 ether2        switch1  voip     default  ignore    ignore    default
 2 ether3        switch1  voip     default  ignore    ignore    default
 3 ether4        switch1  voip     default  ignore    ignore    default
 4 ether5        switch1  voip     default  ignore    ignore    default
 5 ether6        switch1  voip     default  ignore    ignore    default
 6 ether7        switch1  voip     default  ignore    ignore    default
 7 ether8        switch1  voip     default  ignore    ignore    default
 8 ether9        switch1  voip     default  ignore    ignore    default
 9 ether10       switch1  default  default  ignore    ignore    default
10 ether11       switch1  default  default  ignore    ignore    default
11 ether12       switch1  default  default  ignore    ignore    default
12 ether13       switch1  default  default  ignore    ignore    default
13 ether14       switch1  default  default  ignore    ignore    default
14 ether15       switch1  default  default  ignore    ignore    default
15 ether16       switch1  default  default  ignore    ignore    default
16 ether17       switch1  default  default  ignore    ignore    default
17 ether18       switch1  default  default  ignore    ignore    default
18 ether19       switch1  default  default  ignore    ignore    default
19 ether20       switch1  default  default  ignore    ignore    default
20 ether21       switch1  default  default  ignore    ignore    default
21 ether22       switch1  default  default  ignore    ignore    default
22 ether23       switch1  default  default  ignore    ignore    default
23 ether24       switch1  default  default  ignore    ignore    default
24 sfp-sfpplus1  switch1  default  default  trust     ignore    default
25 sfp-sfpplus2  switch1  default  default  ignore    ignore    default
26 switch1-cpu   switch1

With this configuration, incoming packets on port ether1 through ether9 are marked with a Priority Code Point (PCP) value of 5 and a Differentiated Services Code Point (DSCP) value of 46. Incoming packets on port ether10 through ether24 are marked with PCP and DSCP value of 0. When packets are received on the sfp-sfpplus1 port, any packets with a PCP value of 5 retain their PCP value of 5 and DSCP value of 46, while all other packets are marked with PCP and DSCP value of 0.

Dante​

Starting from RouterOS v7.15, all MikroTik QoS-capable devices are compatible with Dante audio networking.

Dante hardware uses the following DSCP/Diffserv priority values for traffic prioritization:

Dante PriorityUsageDSCP LabelDSCP Value
HighTime-critical PTP eventsCS756
MediumAudio, PTPEF46
NoneOther trafficBE0

This example assumes the switch is using its default configuration, which includes a default bridge interface with all Ethernet interfaces added as bridge ports. Any of these interfaces can be used for Dante.

First, create QoS profiles to match Dante traffic classes. There is already a pre-existing "default" profile that corresponds to Dante's None priority.

/interface/ethernet/switch/qos/profile
add name=dante-ptp dscp=56 pcp=7 traffic-class=7
add name=dante-audio dscp=46 pcp=5 traffic-class=5

If you are running RouterOS version 7.23 or later, the IP DSCP mapping is created automatically, so this step is not required. If you are using an earlier RouterOS version, create a QoS mapping to match QoS profile based on DSCP values:

/interface/ethernet/switch/qos/map/ip
add dscp=56 profile=dante-ptp
add dscp=46 profile=dante-audio

Configure the hardware queue to enforce QoS on Dante traffic:

/interface/ethernet/switch/qos/tx-manager/queue
set [find where traffic-class=7] schedule=strict-priority
set [find where traffic-class=5] schedule=strict-priority

Dante's High and Medium priority traffic is scheduled in strict priority order. The device transmits time-critical PTP packets until queue7 is empty, then proceeds with audio (queue5). Other traffic is transmitted only when PTP and audio queues are empty.

The next step is to enable trust mode for incoming Layer 3 packets (IP DSCP field):

/interface/ethernet/switch/qos/port
set [find] trust-l3=keep

Finally, enable QoS hardware offloading for the above settings to take effect:

/interface/ethernet/switch
set switch1 qos-hw-offloading=yes

When using Dante in multicast mode, it is beneficial to enable IGMP snooping on the switch. This feature directs traffic only to ports with subscribed devices, preventing unnecessary flooding. Additionally, enabling an IGMP querier (if not already enabled on another device in the same LAN), adjusting query interval, and activating fast-leave can further optimize multicast performance.

/interface/bridge
set [find name=bridge] igmp-snooping=yes multicast-querier=yes query-interval=60s

/interface/bridge/port
set [find] fast-leave=yes

RDMA over Converged Ethernet (RoCE)​

RoCE enables direct memory access to remote storage systems over Ethernet networks without involving the host CPU. This significantly reduces latency and CPU overhead, making RoCE ideal for high-performance computing and data center environments. RoCE also allows a converged network where various services (such as data storage, networking, and multimedia) run over a single Ethernet infrastructure, simplifying network management and reducing the cost and complexity of maintaining separate networks.

RoCE achieves this through the use of ECN and PFC mechanisms. These features help prevent network congestion and packet loss, ensuring reliable, lossless communication. See the device feature table for compatible switches. While the switch can support a RoCE environment, the end hosts must also be compatible with the RoCE protocol and equipped with RDMA-capable network interface cards (NICs).

There are two main versions of RoCE. RoCEv1 operates as an Ethernet link layer protocol and uses Ethertype 0x8915. RoCEv2 works over standard IP networks, using UDP destination port number 4791. ECN bits in the IP header are marked to signal network congestion, and a Congestion Notification Packet (CNP) is used to acknowledge congestion to the sender. For traffic prioritization, DSCP 26 is used for RoCEv2 traffic, while DSCP 48 is used for CNPs.

The following example can be used for lossless RoCEv2 with PFC and ECN, and it assumes that the switch is using its default configuration, which includes a default bridge interface with all Ethernet interfaces added as bridge ports. The minimal recommended RouterOS version is 7.17.

First, configure additional profiles. Non-RoCE traffic will be assigned to the already existing "default" profile with traffic-class 1, RoCEv2 to traffic-class 3, and CNP to traffic-class 6.

/interface/ethernet/switch/qos/profile
add dscp=26 name=roce traffic-class=3
add dscp=48 name=cnp traffic-class=6

If you are running RouterOS version 7.23 or later, the IP DSCP mapping is created automatically, so this step is not required. If you are using an earlier RouterOS version, create a QoS mapping to match QoS profiles based on DSCP values.

/interface/ethernet/switch/qos/map/ip
add dscp=26 profile=roce
add dscp=48 profile=cnp

Configure hardware queue and scheduler. Use ETS (schedule=high-priority-group) for traffic-class 1 and traffic-class 3 with 50% bandwidth assignment each (weight=1), and strict priority scheduling for traffic-class 6. Additionally, enable ECN (ecn=yes) for traffic-class 3 to mark IP packets in the switch that experience congestion.

/interface/ethernet/switch/qos/tx-manager/queue
set 1 schedule=high-priority-group weight=1
set 3 schedule=high-priority-group weight=1 ecn=yes
set 6 schedule=strict-priority
info

Although using schedule=low-priority-group allows you to create separate ETS scheduling and bandwidth allocation for a different set of traffic-classes, it is not recommended to use this setting together with lldp-dcbx=yes. The reason is that the ETS Configuration/Recommendation TLVs are designed to handle a single bandwidth allocation across traffic classes, thus schedule=high-priority-group should be used instead.

Configure a PFC profile for traffic-class 3 to ensure a lossless environment for RoCEv2 traffic.

/interface/ethernet/switch/qos/priority-flow-control
add name=pfc-tc3 rx=yes traffic-class=3 tx=yes

Set Layer3 trust mode (trust-l3=keep) on switch ports where RoCEv2 traffic is expected. Set PFC (pfc=pfc-tc3) and egress rate for queue3 to comply with PFC requirements (egress-rate-queue3=10.0Gbps). In this example, 10Gbps SFP+ interfaces is used, and the egress rate can be set to match the physical speed of the interface. Change this property depending on your interface speeds.

/interface/ethernet/switch/qos/port
set sfp-sfpplus1 egress-rate-queue3=10.0Gbps pfc=pfc-tc3 trust-l3=keep
set sfp-sfpplus2 egress-rate-queue3=10.0Gbps pfc=pfc-tc3 trust-l3=keep
set sfp-sfpplus3 egress-rate-queue3=10.0Gbps pfc=pfc-tc3 trust-l3=keep
set sfp-sfpplus4 egress-rate-queue3=10.0Gbps pfc=pfc-tc3 trust-l3=keep

Enable QoS hardware offloading for the above settings to start working.

/interface/ethernet/switch
set switch1 qos-hw-offloading=yes

Enable the LLDP Data Center Bridging Capability Exchange Protocol (DCBX) to share QoS settings and capabilities with other neighboring devices.

/ip/neighbor/discovery-settings
set lldp-dcbx=yes

As an optional step, increase the L2MTU to accommodate larger data packets.

/interface/ethernet
set [find switch=switch1] l2mtu=9500

QoS Marking​

Understanding Map Ranges​

To avoid defining every possible PCP and DSCP mapping individually, RouterOS allows you to specify multiple values or ranges for PCP and DSCP when creating QoS profile mappings.

In this example, PCP values 0 and 2 use the default QoS profile, values 1 and 3-4 use the streaming profile, value 5 uses the voip profile, and values 6-7 use the control profile:

/interface/ethernet/switch/qos/map/vlan
add pcp=1,3-4 profile=streaming
add pcp=5 profile=voip
add pcp=6-7 profile=control

This approach simplifies configuration by grouping related priority values together rather than creating separate mappings rules for each individual value.

Understanding Port, Profile, and Map relation​

Each switch port has Layer2 and Layer3 trust settings that will change how ingress packets are classified into QoS profiles and what PCP and DSCP values will be used. Below are tables that describe all possible options:

qos-trust-l2qos-trust-l3Behavior
ignoreignoreThe port is considered untrusted. Both headers are ignored, and the port's profile is forced to all ingress packets. This is the default setting.
ignoretrustTrust the Layer 3 header. Use the DSCP field from the IP header of ingress packets for QoS profile lookup (see /in/eth/sw/qos/map/ip). If the lookup fails (no QoS profiles are mapped to the given DSCP value), the default QoS profile is used (not the switch port's QoS profile). The switch port's profile field is used only for non-IP traffic.
ignorekeepTrust the Layer 3 header. Use the DSCP field from the IP header of ingress packets for QoS profile lookup (see /in/eth/sw/qos/map/ip). If the lookup fails, the default QoS profile is used. The switch port's profile field is used only for non-IP traffic. If the forwarded/routed packet is VLAN-tagged, its PCP value is set from the selected QoS profile. However, the original DSCP value of the packet is kept intact.
trustignoreTrust the Layer 2 header, but ignore L3. If an ingress packet is VLAN-tagged, use the PCP field from the VLAN header for QoS profile lookup (see /in/eth/sw/qos/map/vlan). If the lookup fails (no QoS profiles are mapped to the given PCP value), the default QoS profile is used. The switch port's profile field is used only for untagged traffic.
trusttrustTrust both headers, but Layer 3 has higher precedence. In the case of an IP packet, use the DSCP field for QoS profile lookup (see /in/eth/sw/qos/map/ip). If the DSCP-to-QoS lookup fails, use the default profile. If the packet is not an IP packet but is VLAN-tagged, use the PCP field from the VLAN header for QoS profile lookup (see /in/eth/sw/qos/map/vlan). If the VLAN-to-QoS lookup fails, use the default QoS profile. Non-IP untagged packets use the switch port's profile.
trustkeepThe same as trust+trust, but the original DSCP value is preserved in forwarded/routed packets.
keepignoreTrust the Layer 2 header but ignore L3. If an ingress packet is VLAN-tagged, use the PCP field from the VLAN header for QoS profile lookup (see /in/eth/sw/qos/map/vlan). If the lookup fails (no QoS profiles are mapped to the given PCP value), the default QoS profile is used. The switch port's profile field is used only for untagged traffic. If the packet is VLAN-tagged on both ingress and egress, the original PCP value is kept.
keeptrustTrust both headers, but Layer 3 has higher precedence. In the case of an IP packet, use the DSCP field for QoS profile lookup (see /in/eth/sw/qos/map/ip). If the DSCP-to-QoS lookup fails, use the default profile. If the packet is not an IP packet but is VLAN-tagged, use the PCP field from the VLAN header for QoS profile lookup (see /in/eth/sw/qos/map/vlan). If the VLAN-to-QoS lookup fails, use the default QoS profile. Non-IP untagged packets use the switch port's profile. If the packet is VLAN-tagged on both ingress and egress, the original PCP value is kept. The DSCP value in forwarded/routed packets is set from the selected QoS profile.
keepkeepTrust both headers, but Layer 3 has higher precedence. In the case of an IP packet, use the DSCP field for QoS profile lookup (see /in/eth/sw/qos/map/ip). If the DSCP-to-QoS lookup fails, use the default profile. If the packet is not an IP packet but is VLAN-tagged, use the PCP field from the VLAN header for QoS profile lookup (see /in/eth/sw/qos/map/vlan). If the VLAN-to-QoS lookup fails, use the default QoS profile. Non-IP untagged packets use the switch port's profile. Keep both the original PCP and/or DSCP values intact in cases of VLAN-tagged and/or IP packets, respectively.
Port settingsThe selected QoS profile and the source for PCP / DSCP field values in forwarded/routed packets
qos-trust-l2qos-trust-l3VLAN-Tagged IPUntagged IPVLAN-Tagged Non-IPUntagged Non-IP
QoS ProfilePCPDSCPQoS ProfilePCP 1DSCPQoS ProfilePCPDSCPQoS ProfilePCP 1DSCP
ignoreignoreprofileprofileprofileprofileprofileprofileprofileprofile-profileprofile-
ignoretrustmap/ipmap/ipmap/ipmap/ipmap/ipmap/ipprofileprofile-profileprofile-
ignorekeep/map/ip/map/iporiginal/map/ip/map/iporiginalprofileprofile-profileprofile-
trustignoremap/vlanmap/vlanmap/vlanprofileprofileprofilemap/vlanmap/vlan-profileprofile-
trusttrust/map/ip/map/ip/map/ip/map/ip/map/ip/map/ip/map/vlan/map/vlan-profileprofile-
trustkeep/map/ip/map/iporiginal/map/ip/map/iporiginal/map/vlan/map/vlan-profileprofile-
keepignoremap/vlanoriginalmap/vlanprofileprofileprofilemap/vlanoriginal-profileprofile-
keeptrustmap/iporiginalmap/ipmap/ipprofilemap/ipmap/vlanoriginal-profileprofile-
keepkeepmap/iporiginaloriginalmap/ipprofileoriginalmap/vlanoriginal-profileprofile-

1 Applies only when ingress traffic is untagged, but the egress interface requires the frames to be VLAN-tagged.

QoS Marking via Switch Rules (ACL)​

Starting from RouterOS v7.15, you can assign QoS profiles to network traffic using Switch Rules (ACL). This method allows for flexible traffic classification based on various packet attributes.

Sub-menu: /interface/ethernet/switch/rule

New/Changed PropertiesDescription
new-qos-profile (name)The name of the QoS profile to assign to the matched packets.
keep-qos-fields (yes | no; Default: no)Should the original values of QoS fields (PCP, DSCP) be kept (yes), or replaced with the ones from the assigned QoS profile (no)? Relevant only if new-qos-profile is set.
new-vlan-priority (0..7)Deprecated and should be replaced with the respective new-qos-profile. Kept for backward compatibility. Relevant only if qos-hw-offloading=no.

The following example assigns a QoS profile based on the source MAC address:

/interface/ethernet/switch/rule
add new-qos-profile=stream port=ether1,ether2 src-mac-address=00:01:02:00:00:00/FF:FF:FF:00:00:00 switch=switch1
add new-qos-profile=voip port=ether1,ether2 src-mac-address=04:05:06:00:00:00/FF:FF:FF:00:00:00 switch=switch1

QoS Enforcement​

Hardware Queues​

Each switch port has eight hardware transmission (Tx) queues (queue0 through queue7). Each queue corresponds to a traffic class (tc0 through tc7) defined by a QoS profile. When a packet enters the switch, it receives a QoS profile assignment, which determines the traffic class and consequently selects the appropriate egress queue for transmission.

Hardware queues have variable sizes configured by the Transmission Manager. Additionally, multiple ports and queues can share resources with each other through a mechanism called Shared Buffers. For example, a device with 25 ports has buffer memory sufficient to queue 1200 packets total. If resources are split equally, each port receives 48 exclusive buffers with a maximum of 6 packets per queue (48 divided by 8), which is typically insufficient to absorb even a short traffic burst. However, allocating 50% of buffers for sharing leaves each port with 24 exclusive buffers (3 per queue), while simultaneously allowing a single queue to grow up to 603 buffers (3 exclusive plus 600 shared).

RouterOS enables enabling or disabling the shared pool for each queue individually. This capability helps prevent low-priority traffic from consuming all available hardware memory. Additionally, port buffer limits can restrict a single low-speed port from occupying the entire shared pool. For more details, see QoS Settings and Transmission Manager.

info

The default best-effort traffic class (PCP=0, DSCP=0) is traffic class 1, while the lowest priority traffic (PCP=1) uses traffic class 0.

Hardware Resources​

The switch chip has limited hardware resources (memory). Two main hardware resources are relevant to QoS operations:

  • Packet descriptor - Contains packet control information such as the target port, header modifications, and other metadata.
  • Data buffer - Memory chunk that stores the actual packet payload. Buffer size varies depending on the switch chip model; typically 256 bytes.

One packet descriptor may use multiple buffers (depending on the payload size), and buffers may be shared by multiple descriptors in cases of multicast or broadcast traffic. If the hardware does not have enough free descriptors or buffers, the packet gets dropped (tail-drop).

Hardware resources can be limited per destination type (multicast/unicast), per port, and per TX queue. When any of these limits are reached, no additional packets can be enqueued for transmission, and subsequent packets get dropped.

RouterOS abstracts low-level hardware details, allowing resource limits to be configured either in terms of packets or as a percentage of the total amount. RouterOS automatically calculates the required hardware descriptor and buffer count based on the user-specified packet limit and port's MTU. Additionally, RouterOS includes preconfigured hardware resources, eliminating the need for manual configuration in common QoS scenarios.

danger

Modifying any hardware resource allocation parameter at runtime causes a temporary device halt during which no packets can be enqueued or transmitted. Temporary packet loss is expected while the device is forwarding traffic.

Resource Saving (Previous Generation Devices)​

info

This section applies only to devices that do not support Dynamic Buffers.

Because hardware resources cannot be reallocated at runtime, RouterOS cannot automatically release queue buffers reserved for inactive ports. These buffers remain unused. However, if you know that a specific port will never be used (for example, it stays physically disconnected), you can manually free the corresponding queue resources by assigning the built-in "offline" tx-manager with minimum resources:

/interface/ethernet/switch/qos/port
set sfp-sfpplus1 tx-manager=offline
set sfp-sfpplus2 tx-manager=offline
danger

Do not configure the "offline" tx-manager on the switch-cpu port.

caution

When configuring the tx-manager setting for a QSFP+ or QSFP28 interface, you must apply the same configuration to all four sub-interfaces of that port. For example, if interface qsfp28-1-1 is active and linked at 100Gbps, while sub-interfaces (qsfp28-1-2, qsfp28-1-3, qsfp28-1-4) show a non-running flag, do not assign the "offline" tx-manager to those non-running sub-interfaces. Doing so will affect the 100Gbps link as well. However, if none of the four sub-interfaces are running, it is safe to assign the "offline" tx-manager setting.

Traffic Prioritization​

The hardware supports two types of traffic transmission prioritization:

  • Strict Priority - traffic from higher queues is always transmitted first.
  • Enhanced Transmission Selection (ETS) - multiple queues participate in packet transmission scheduling at the same time using weighted round-robin.

Strict Priority queuing is straightforward. If the highest priority queue (Q7) has packets, those are transmitted first. When Q7 is empty, packets from Q6 get transmitted, and so on. The packets from the lowest priority queue (Q0) are transmitted only if all other queues are empty.

The downside of strict prioritization is increased latency in lower queues while "overprioritizing" higher queues. Suppose the acceptable latency of TC5 is 20ms, TC3 - 50ms. Traffic appearing in Q5 gets immediately transmitted due to the strict priority of the queue, adding extra latency to every packet in the lower queues (Q4..Q0). A packet burst in Q5 (e.g., a start of a voice call) may temporarily "paralyze" Q3, increasing TC3 latencies over the acceptable 50ms (or even causing packet drops due to a full queue) while TC5 packets get transmitted at <1ms (way below the 20ms limit). Slightly sacrificing TC5 latency by transmitting TC3 packets in between would make everybody happy. That is what ETS is for.

Enhanced Transmission Selection (ETS) schedules traffic for transmission from multiple queues (group members) in a weighted round-robin manner. A queue's weight sets the number of packets transmitted from the queue in each round. For example, if Q2, Q1, and Q0 are the group members, and their weights are 3, 2, and 1, respectively, the scheduler transmits 3 packets from Q2, 2 from Q1, and 1 from Q0. The actual transmission order in each round of the above example is "Q2, Q1, Q0, Q2, Q1, Q2" - for even fairer scheduling.

There are two hardware groups: low-priority-group and high-priority-group. There is a strict priority ordering between the two groups: the low-priority-group transmits only when all queues in the high-priority-group are empty. However, it is possible to use only one group for all queues.

The default (built-in) RouterOS queue setup is listed below. Q3-Q5 share the bandwidth within the high-priority group, where packets are transmitted while Q6 and Q7 are empty. Q0-Q2 are the members of the low-priority-group, where packets are transmitted while Q3-Q7 are empty.

[admin@MikroTik] /interface/ethernet/switch/qos/tx-manager/queue> print 
Columns: TX-MANAGER, TRAFFIC-CLASS, SCHEDULE, WEIGHT, QUEUE-BUFFERS, USE-SHARED-BUFFERS
#  TX-MANAGER  TRAFFIC-CLASS  SCHEDULE             WEIGHT  QUEUE-BUFFERS  USE-SHARED-BUFFERS
0  default     0              low-priority-group   1       auto           no                
1  default     1              low-priority-group   2       auto           yes                
2  default     2              low-priority-group   3       auto           yes                
3  default     3              high-priority-group  3       auto           yes               
4  default     4              high-priority-group  4       auto           yes               
5  default     5              high-priority-group  5       auto           yes               
6  default     6              strict-priority              auto           yes               
7  default     7              strict-priority              auto           yes
info

It is recommended that all group members are adjacent to each other.

Active Queue Management (AQM)​

Weighted Random Early Detection (WRED)​

WRED is a congestion control mechanism that operates on a per-queue basis. It signals congestion events to end-point devices by dropping packets before queue overflow occurs. WRED relies on rate throttling mechanisms in end-points that respond to packet loss, such as TCP/IP.

WRED uses a randomized packet drop algorithm to anticipate congestion events and respond to them by throttling traffic rates before congestion actually happens. The randomness property of WRED prevents throughput collapse caused by global synchronization of TCP flows.

WRED can be enabled or disabled per queue in each Tx Manager. Disable WRED for lossless traffic classes. There is also no reason to enable WRED on high-speed ports where congestion should not occur in the first place.

The behavior is controlled via the WRED threshold. The WRED threshold defines the maximum number of packets or bytes that can exceed the queue's shared buffer limit (cap). Random packet drops begin when queue usage exceeds its respective capacity:

  • queueX-packet-use > queueX-shared-packet-cap, or
  • queueX-byte-use > queueX-shared-byte-cap.

The more the usage exceeds the capacity, the higher the packet drop chance becomes, reaching 100% at queueX-shared-packet-cap + wred-packet-threshold (or byte equivalent).

RouterOS automatically selects the actual WRED threshold values based on queue or shared pool capacities. The user can adjust the thresholds via the QoS Settings.

danger

WRED requires the respective Tx queue to use shared buffers (use-shared-buffers=yes).

Choosing a WRED threshold value involves a tradeoff between congestion anticipation and burst absorption. Setting a higher WRED threshold may lead to earlier traffic rate throttling and, therefore, resolve congestion. However, a high threshold causes packet drops in limited traffic bursts that could be absorbed by the queue buffers and transmitted losslessly if WRED didn't activate.

For example, initiating a remote database connection usually starts with heavier traffic (a "packet burst") during the initialization phase, then the traffic rate drops to a "reasonable" level. Any packet drop during the initialization phase results in a slower database connection due to the need for retransmission. Therefore, lowering the WRED threshold or entirely disabling WRED on such traffic is recommended. The opposite case is video streaming, where early congestion detection helps select a comfortable streaming rate without losing too much bandwidth on retransmission or sacrificing quality level.

info

Use Switch Rules (ACL) or other QoS Marking techniques to differentiate traffic and place packets into queues with the desired WRED settings.

The following script applies WRED only to TCP/IP traffic by redirecting it to queue2. UDP and other packets remain in queue1 since their end-points typically cannot respond to early drops. Queue1 and queue2 are scheduled equally without prioritizing one queue over another:

/interface/ethernet/switch/qos/profile
add name=tcp-wred traffic-class=2 pcp=0 dscp=0

# move TCP traffic to queue2
/interface/ethernet/switch/rule
add new-qos-profile=tcp-wred ports=ether1,ether2,ether3,ether4 protocol=tcp switch=switch1

# set the same scheduling priority (weight) between queue1 and queue2
# apply WRED only to queue2 - TCP traffic
/interface/ethernet/switch/qos/tx-manager/queue/
set [find where traffic-class=1] weight=2 schedule=low-priority-group use-shared-buffers=yes wred=no
set [find where traffic-class=2] weight=2 schedule=low-priority-group use-shared-buffers=yes wred=yes

Explicit Congestion Notification (ECN)​

Certain switch chip models support hardware-level ECN marking for IP packets, compliant with RFC 3168. This mechanism operates similarly to WRED but, instead of dropping packets during congestion, it marks them with the CE (Congestion Experienced, binary 11) flag in the ECN field. Only ECN-capable IP packets can receive this mark—those with the ECN field value set to ECT(1) or ECT(0) (binary 01 or 10). Non-ECN-capable transport packets (ECN=00) are never marked. If a packet already carries the CE mark (ECN=11), it retains this designation regardless of whether the device experiences congestion.

Enable ECN marking by setting ecn=yes on the desired Tx Manager Queue.

danger

The ECN marking mechanism requires the respective Tx queue to use shared buffers (use-shared-buffers=yes).

A packet receives the CE mark when all of the following conditions are met:

  1. The packet is IPv4 or IPv6.
  2. The ECN field value in the IP header is either ECT(1) or ECT(0).
  3. The egress port's Tx Queue has ecn=yes enabled and uses shared buffers (use-shared-buffers=yes).
  4. Queue usage exceeds the shared buffer capacity: queueX-packet-use > queueX-shared-packet-cap or queueX-byte-use > queueX-shared-byte-cap.
danger

Since enabling ECN (ecn=yes) prevents ECN-capable packet drops, queue usage may exceed WRED thresholds if the traffic sender does not respond to congestion notification in time.

Priority-based Flow Control (PFC)​

Priority-based Flow Control (PFC) enables lossless operation for up to eight traffic classes, ensuring that congestion in one traffic class does not pause traffic in other classes. This allows loss-sensitive traffic types to coexist with loss-tolerant traffic types on the same network.

PFC-capable switch chips comply with IEEE 802.1Qbb PFC standard, meaning they can generate and respond to PFC frames. When congestion occurs on an egress port, the source port transmits a PFC frame for the affected traffic class. The generated PFC frames use timer value 0xFFFF for pause (XOFF) and 0x0 for resume (XON), with the appropriate bit set in the priority enable vector. On the receiving end, the PFC frame pauses the specific priority queues on the destination port for the duration specified in the PFC frame.

In RouterOS, PFC configuration is organized into profiles. Each port can be assigned to a specific PFC profile, which defines the traffic classes to enable PFC on, the pause and resume thresholds for sending XOFF and XON frames respectively, and whether the assigned ports should transmit and/or receive PFC frames.

When congestion occurs on an egress port, PFC is triggered on the ingress port. Shared buffers must be used to associate the amount of ingress traffic with the packets waiting in Tx queues. For each PFC-enabled traffic class, set use-shared-buffers=yes on the corresponding Tx queue.

info

RouterOS implements a 1:1 mapping between traffic classes and Tx queues. Packets with traffic class 0 are enqueued in queue0, TC1 in queue1, and so on up to TC7 in queue7. Therefore, the terms "traffic class" and "Tx queue" are used interchangeably throughout this documentation.

When selecting pause and resume thresholds, account for the delay in transmitting and processing PFC frames. For example, device A experiences congestion at time T, sends a PFC pause frame to device B, and B processes the frame and stops transmitting at time T+D. During the delta time D, device B continues sending traffic. If device A has configured the pause threshold to 100%, it has no free buffers available, and packets may drop, which is unacceptable for lossless traffic classes. Setting a lower pause threshold, such as 80%, sends a PFC pause frame while still retaining free memory to absorb traffic during the delta time D. The same principle applies to the resume threshold. Setting it to 0% keeps the device idle during the delta time, reducing overall throughput.

PFC receive requires setting the egress rate for all associated queues to calculate pause time, even if it matches the wire speed. For example, if PFC runs on traffic class 3, the assigned ports require the egress-rate-queue3 setting.

/interface/ethernet/switch/qos/priority-flow-control/add name=pfctc3 traffic-class=3 rx=yes
/interface/ethernet/switch/qos/port/set sfp-sfpplus1,sfp-sfpplus2 pfc=pfctc3 egress-rate-queue3=10G

Property Reference​

Switch settings​

Sub-menu: /interface/ethernet/switch

Switch QoS settings (in addition to the existing ones).

PropertyDescription
qos-hw-offloading (yes | no; Default: no)Allows enabling QoS for the given switch chip (if it supports QoS).
New generation devices force qos-hw-offloading=yes at all times.
info

When you enable QoS, turning off the qos-hw-offloading setting will not completely revert to the previous functionality. It is recommended to reboot the device after disabling it.

Port Settings​

Sub-menu: /interface/ethernet/switch/qos/port

This sub-menu configures QoS settings for individual switch ports. It allows you to assign a QoS profile to ingress packets arriving on a specific port. If the port is configured as trusted, the assigned profile can be overridden by match rules based on packet header values.

By default, all ports are untrusted and receive the default QoS profile (Best-Effort, PCP=0, DSCP=0). In this default state, priority fields are cleared from egress packets.

Port Stats​

Example

[admin@Mikrotik] /interface/ethernet/switch/qos/port> print stats where name=ether2
                  name:     ether2
             tx-packet:      2 887
               tx-byte:  3 938 897
           drop-packet:      1 799
             drop-byte:  2 526 144
      tx-queue0-packet:         50
      tx-queue1-packet:      1 871
      tx-queue3-packet:        774
      tx-queue5-packet:        192
        tx-queue0-byte:      3 924
        tx-queue1-byte:  2 468 585
        tx-queue3-byte:  1 174 932
        tx-queue5-byte:    291 456
    drop-queue1-packet:      1 799
      drop-queue1-byte:  2 526 144
PropertyDescription
namePort name.
tx-packetThe total number of packets transmitted via this port.
tx-byteThe total number of bytes transmitted via this port.
drop-packetThe total number of packets that should have been transmitted via this port but were dropped due to a lack of resources (e.g., queue buffers) or QoS Enforcement.
drop-byteThe total number of bytes that should have been transmitted via this port but were dropped.
tx-queue0-packet .. tx-queue7-packetThe number of packets transmitted via this port from the respective queue.
tx-queue0-byte .. tx-queue7-byteThe number of bytes transmitted via this port from the respective queue.
drop-queue0-packet .. drop-queue7-packetThe number of packets dropped from the respective queue (or not enqueued at all due to lack of resources).
drop-queue0-byte .. drop-queue7-byteThe number of bytes dropped from the respective queue.

Port Resources/Usage​

danger

Due to hardware limitations, some switch chip models may break traffic flow while accessing QoS port usage data. Use port usage for diagnostics/troubleshooting only. For monitoring, use QoS monitor or Port stats instead.

Example

[admin@crs326] /interface/ethernet/switch/qos/port> print usage where name=ether2
                 name:  ether2
           packet-cap:     136
           packet-use:       5
             byte-cap:  35 840
             byte-use:   9 472
    queue0-packet-cap:     130
    queue0-packet-use:       1
    queue1-packet-cap:       5
    queue1-packet-use:       4
    queue3-packet-cap:      65
    queue3-packet-use:       2
      queue0-byte-cap:  24 576
      queue0-byte-use:     256
      queue1-byte-cap:   7 680
      queue1-byte-use:   6 144
      queue3-byte-cap:  14 080
      queue3-byte-use:   3 072
PropertyDescription
namePort name.
packet-capPort's packet capacity. The maximum number of packets that can be enqueued for transmission via the port.
packet-use 1Port's packet usage. The number of packets that are currently enqueued in all port's queues.
byte-capPort's byte capacity (buffer size). The maximum number of bytes that can be enqueued for transmission via the port.
byte-use 1Port's byte usage. The size of hardware buffers (in bytes) that are currently allocated for the enqueued packets. Since the buffers are allocated by blocks (usually - 256B each), the allocated buffer size can be bigger than the actual payload.
queue0-packet-cap .. queue7-packet-cap 2Individual queue capacity. The maximum number of packets that can be enqueued in the respective queues (unless the Shared Buffers are enabled).
queue0-shared-packet-cap .. queue7-shared-packet-cap 2Shared queue capacity (individual queue capacity + shared buffers). The maximum number of packets that can be enqueued in the respective queues.
queue0-packet-use .. queue7-packet-use 2Queue packet usage. The number of enqueued packets in the respective queues.
queue0-byte-cap .. queue7-byte-cap 2Individual queue capacity. The maximum number of bytes that can be enqueued in the respective queues (unless the Shared Buffers are enabled).
queue0-shared-byte-cap .. queue7-shared-byte-cap 2Shared queue capacity (individual queue capacity + shared buffers). The maximum number of bytes that can be enqueued in the respective queues.
queue0-byte-use .. queue7-byte-use 2Queue buffer usage (in bytes). The size of hardware buffers (in bytes) that are currently allocated for packets in the respective queues.
queue0-byte-max .. queue7-byte-max 2Maximum queue buffer fill level (in bytes). Available only on devices that provide the queue statistics service. Use the reset-counters command to reset values.

1 Port's packet/byte usage can exceed the capacity if Shared Buffers are enabled.
2 Only the queues in use are printed.

Port PFC Stats (Previous Generations)​

Example

[admin@crs317] /interface/ethernet/switch/qos/port> print pfc interval=1 where running
                 name:  sfp-sfpplus1 sfp-sfpplus2   ether1
                  pfc:          roce     disabled disabled
               pfc-tx:            46            
        pfc-paused-tc:             3            
 pfc3-pause-threshold:     1 048 576            
pfc3-resume-threshold:        10 240            
             pfc3-use:     1 075 200
PropertyDescription
namePort name.
pfcPFC profile name.
pfc-rxReceived PFC frame count.
pfc-txTransmitted PFC frame count.
pfc-paused-tcThe list of traffic classes that should be paused (from the sender's perspective). PFC pause frames (XOFF) are periodically sent with the listed timers set from this port.
pfc0-pause-threshold .. pfc7-pause-thresholdPause thresholds of the respective traffic classes. Only PFC-enabled traffic classes are displayed.
pfc0-resume-threshold .. pfc7-resume-thresholdResume thresholds of the respective traffic classes. Only PFC-enabled traffic classes are displayed.
pfc0-use .. pfc7-useThe current buffer usage of the respective traffic classes (in bytes). In other words, it is the total size of all queued packets on all ports that were received from this port. Only PFC-enabled traffic classes are displayed.

Port PFC Stats (New Generations)​

Example

[admin@crs812] /interface/ethernet/switch/qos/port> print pfc interval=1 where pfc=roce
                 name:       sfp56-5 
                  pfc:          roce
             rx-pause:           287              
             tx-pause:            46             
             pfc3-use:     2 184 200
PropertyDescription
namePort name.
pfcPFC profile name.
pfc0-use .. pfc7-useThe current buffer usage of the respective traffic classes (in bytes). In other words, it is the total size of all queued packets on all ports that were received from this port. Only PFC-enabled traffic classes are displayed.
rx-pauseReceived pause frame count.
tx-pauseTransmitted pause frame count.

QoS Menu​

Sub-menu: /interface/ethernet/switch/qos

The entire QoS hardware configuration is located under /in/eth/sw/qos. This centralized approach allows you to store all QoS-related configuration items in one place, making it easy to monitor and export settings using /in/eth/sw/qos/export.

QoS entries have two major flag indicators:

  • H - Hardware-offloaded entry.
  • I - Inactive entry.

QoS Settings​

Sub-menu: /interface/ethernet/switch/qos/settings

PropertyDescription
mirror-buffers (percent*: 1..90*; Default: auto)Maximum number of packet buffers for mirrored traffic (% of the total buffer memory).
mirror-profile (name; Default: default)The name of the QoS profile to assign to the mirrored packets (see /in/eth/sw/qos/profile).
multicast-buffers (percent*: 1..90*; Default: auto)Maximum number of packet buffers for multicast/broadcast traffic (% of the total buffer memory).
shared-buffers (percent*: 0..90*; Default: auto)Maximum number of packet buffers that are shared between ports (% of the total buffer memory). Setting it to 0 disables buffer sharing. The remaining buffer memory is split between the ports.
All buffers are treated as shared on new generation switch chips that use Dynamic Buffers. The switch chip automatically adjusts port and queue buffer limits based on the current congestion level. Using the auto value allows the device to utilize 100% of the available buffer memory, which is the recommended setting for most scenarios. In specific use cases where latency is more important than avoiding packet drops, the buffer limit can be manually reduced.
lossless-buffers(percent*: 0..100*; Default: auto)If the device supports multiple shared buffer pools, this setting allows adjusting the size of the lossless pool (% of the shared buffer memory, where 100% means all shared buffers allocated by the shared-buffers setting). For example, if shared-buffers=50 and lossless-buffers=80, the lossless pool receives 40% of the total buffer memory (80% of 50% or "0.8 * 0.5 = 0.4"), and the lossy pool receives the remaining 10% of shared buffers.
lossless-traffic-class(integer array: 0..7; Default: auto)The list of lossless traffic classes.
wred-threshold(*low | medium | high;*Default: medium)A relative number of packets above a shared queue cap (queueX-shared-packet-cap or queueX-shared-byte-cap) where random drops take place. This threshold is applied only to queues with enabled Weighted Random Early Detection (wred=yes) that use shared buffers (use-shared-buffers=yes). The higher the queue buffer fill level, the higher the packet drop chance. The low threshold means the random tail drop starts later; the high - sooner.

QoS Monitor​

Command:/interface/ethernet/switch/qos/monitor

Example​

[admin@crs312] /interface/ethernet/switch/qos> monitor once
           total-packet-cap: 11 480   
           total-packet-use: 0        
             total-byte-cap: 2648.0KiB
             total-byte-use: 0        
       multicast-packet-cap: 1 148    
       multicast-packet-use: 0        
         multicast-byte-cap: 264.8KiB 
         multicast-byte-use: 0        
  mirror-ingress-packet-cap: 1 148    
  mirror-ingress-packet-use: 0        
    mirror-ingress-byte-cap: 264.8KiB 
    mirror-ingress-byte-use: 0        
   mirror-egress-packet-cap: 1 148    
   mirror-egress-packet-use: 0        
     mirror-egress-byte-cap: 264.8KiB 
     mirror-egress-byte-use: 0        
      lossy-pool-packet-cap: 2 301    
      lossy-pool-packet-use: 0        
   lossless-pool-packet-cap: 2 301    
   lossless-pool-packet-use: 0        
        lossy-pool-byte-cap: 530.0KiB 
        lossy-pool-byte-use: 0        
     lossless-pool-byte-cap: 530.0KiB 
     lossless-pool-byte-use: 0

Monitors hardware QoS resources.

PropertyDescription
total-packet-cap (integer)Total packet capacity. The maximum number of hardware packet descriptors that the device can store in all queues.
total-packet-use (integer)Total packet usage. The current number of packet descriptors residing in the hardware memory.
total-byte-cap (byte)Total tx memory capacity.
total-byte-use (byte)Total tx memory usage. The current number of bytes occupied by the packets in all tx queues.
multicast-packet-cap*(integer)*Multicast packet capacity. The maximum number of hardware packet descriptors that can be used by multicast/broadcast traffic. Depends on the multicast-buffers setting.
multicast-packet-use (integer)Multicast packet usage. The hardware makes a copy of the packet descriptor for each multicast destination.
mirror-ingress-packet-cap (integer)Ingress mirror packet capacity. The maximum number of hardware packet descriptors that can be used by ingress mirrored traffic. Depends on the mirror-buffers setting.
mirror-ingress-packet-use (integer)Ingress mirror packet usage.
mirror-ingress-byte-cap (byte)Ingress mirror byte capacity. Depends on the mirror-buffers setting.
mirror-ingress-byte-use (byte)Ingress mirror byte usage.
mirror-egress-packet-cap (integer)Egress mirror packet capacity. The maximum number of hardware packet descriptors that can be used by egress mirrored traffic. Depends on the mirror-buffers setting.
mirror-egress-packet-use (integer)Egress mirror packet usage.
mirror-egress-byte-cap (byte)Egress mirror byte capacity. Depends on the mirror-buffers setting.
mirror-egress-byte-use (byte)Egress mirror byte usage.
shared-packet-cap (integer)Shared packet capacity. The maximum number of hardware packet descriptors that can be shared between ports and tx queues. Depends on the shared-buffers setting.
shared-packet-use (integer)Shared packet usage. The current number of shared packet descriptors used by all tx queues.
shared-byte-cap (byte)Shared tx memory capacity. Depends on the shared-buffers setting.
shared-byte-use (byte)Shared tx memory usage. The current number of shared buffers occupied by the packets in all tx queues.
lossy-pool-packet-cap(integer)Shared packet capacity of the lossy pool. The field is omitted if the device does not support multiple shared pools.
lossy-pool-packet-use (integer)Shared packet usage of the lossy pool. The field is omitted if the device does not support multiple shared pools.
lossless-pool-packet-cap (integer)Shared packet capacity of the lossless pool. The field is omitted if the device does not support multiple shared pools.
lossless-pool-packet-use (integer)Shared packet usage of the lossless pool. The field is omitted if the device does not support multiple shared pools.
wred-packet-cap (integer)The maximum packet count that a queue can use above the shared cap (queueX-shared-packet-cap in /in/eth/sw/qos/port/print usage) to trigger a random tail drop. For example, if queue1-shared-packet-cap=3072 and wred-packet-cap=512, WRED triggers when queue1-packet-use exceeds 3072, reaching 100% drop rate at 3072+512=3584 packets.
wred-byte-cap (integer)The maximum byte count that a queue can use above the shared cap (queueX-shared-byte-cap) to trigger a random tail drop. For example, if queue1-shared-byte-cap=768KiB and wred-byte-cap=128KiB, WRED triggers when queue1-packet-use exceeds 768KiB, reaching 100% drop rate at 768+128=896KiB.

QoS Profile​

Sub-menu: /interface/ethernet/switch/qos/profile

QoS profiles determine priority field values (PCP, DSCP) for the forwarded/routed packets. Congestion avoidance/resolution is based on QoS profiles. Each packet gets a QoS profile assigned based on the ingress switch port QoS settings (see /in/eth/sw/port).

PropertyDescription
color (green | yellow | red; Default: green)Traffic color for color-aware drop precedence management. Leave the default value (green) for color-blind drop precedence management.
dscp (integer: 0..63; Default: 0)IPv4/IPv6 DSCP field value for the egress packets assigned to the QoS profile.
name (string; Default: )The user-defined name of the QoS profile.
pcp (integer: 0..7; Default: 0)VLAN priority value (IEEE 802.1q PCP - Priority Code Point). Used only if the egress packets assigned to the QoS profile are VLAN-tagged (have the 802.1q header). The value can be further altered via the QoS Egress Map.
traffic-class (integer: 0..7; Default: 0)The traffic class determines the packet priority and the egress queue (see tx-manager). The queue number is usually the same as the traffic class (packets with tc0 go into queue0, tc1 - queue1, ... tc7 - queue7). Unlike pcp, where 0 means the default priority but 1 - the lowest one (and further customizable), traffic classes are strictly ordered. TC0 always selects the lowest priority, etc.
automap(yes*| no*; Default: yes)Automatically maps packets with matching PCP or DSCP values to this QoS profile. Only applies to trusted ports.

QoS Mapping​

Sub-menu: /interface/ethernet/switch/qos/map

Priority-to-profile mapping table(-s) for trusted packets. All switch chips have one built-in map - default. In addition, some models allow the user to define custom mapping tables and assign different maps to various switch ports via the qos-map property:

  • Devices based on Marvell Prestera 98DX224S, 98DX226S, or 98DX3236 switch chip models support only one map - default.
  • Devices based on Marvell Prestera 98DX8xxx, 98DX4xxx switch chips, or 98DX325x model devices support up to 12 maps (the default + 11 user-defined).
PropertyDescription
name (string; Default: )The user-defined name of the mapping table.

VLAN Map​

Sub-menu: /interface/ethernet/switch/qos/map/vlan

Matches VLAN priorities (802.1p PCP/DEI fields) to QoS profiles. By default, all values are matched to the default QoS profile.

PropertyDescription
dei-only (yes | no; Default: no)Maps only packets with DEI (formerly CFI) bit set in the VLAN header.
map (name; Default: default)The name of the mapping table.
profile (name; Default: )The name of the QoS profile to assign to the matched packets.
pcp (range: 0..7; Default: 0)VLAN priority (PCP) value(-s) for the lookup.

DSCP Map​

Sub-menu: /interface/ethernet/switch/qos/map/ip

Matches DSCP values to QoS profiles.

PropertyDescription
dscp (range: 0..63; Default: 0)DSCP value(-s) for the lookup.
map (name; Default: default)The name of the mapping table. If not set, the standard (built-in) mapping table gets altered.
profile (name; Default: )The name of the QoS profile to assign to the matched packets.

Transmission Manager​

Sub-menu: /interface/ethernet/switch/qos/tx-manager

Transmission (Tx) Manager controls packet enqueuing for transmission and packet tx order. Different switch ports can be assigned to different Tx managers. The maximum number of hardware Tx managers depends on the switch chip model.

PropertyDescription
name (string; Default: )The user-defined name of the Tx Manager
queue-buffers*(percent: 0%..100% | bytes | auto;*Default:auto)The total number of hardware Tx buffers allocated to all ports linked to this Tx Manager. Any value but auto is NOT scaled by the number of ports. For example, if queue-buffers=30%, and there are 3 ports using this Tx Manager, each respective port receives 10% of the total available resources. Adding two more ports to the Tx Manager drops per-port buffers down to 6% (30/5).
info

Port status has no effect on the allocated resources. Running ports receive the same amount of queue buffers as disconnected or disabled ones if all of them are assigned to the same Tx Manager.

Transmission Queue Scheduler​

Sub-menu: /interface/ethernet/switch/qos/tx-manager/queue

Each port has eight Tx queues. The assigned Tx Manager controls packet enqueuing and schedules transmission orders. Each queue can have either strict priority (where packets with the highest traffic class are always transmitted first) or be grouped together for a weighted round-robin tx schedule.

Creating a Tx Manager automatically creates all eight respective queue schedulers.

danger

Changing any properties of Tx manager or queues completely halts traffic enqueueing and transmission during the offload process. Temporary packet loss is expected while the device is forwarding traffic.

PropertyDescription
tx-manager (name; read-only)The linked Tx Manager
traffic-class (integer: 0..7; read-only)The traffic class (tc0..tc7) and the respective port queue (queue0..queue7) that the scheduler controls.
schedule(strict-priority | high-priority-group | low-priority-group )
  • strict-priority - packets in the respective queue are always scheduled before moving to lower traffic classes. Packets with lower traffic classes are not transmitted until the current queue is empty.
  • high-priority-group - all queues in the group are scheduled together by using a weighted round-robin principle. For example, if TC5 has weight 4, TC4 - 3, and TC3 - 2, then the scheduler transmits 4 packets from queue5, 3 packets from Q4, and 2 packets from Q3 in a single round. To achieve lower latency, each round is "sliced" between all queues in the group. In other words, the packet order in each round of the above example is "Q5, Q4, Q3, Q5, Q4, Q3, Q5, Q4, Q5".
  • low-priority-group - similar logic to the high-priority-group, but the low-priority-group is scheduled only when all queues in the high-priority-group are empty.
weight (integer: 0..255; Default: 1)The weight value for the traffic class if it is a member of a schedule group. The field is not used in the case of a strict priority schedule.
queue-buffers*(percent: 0%..100% | bytes | auto;*Default:auto)The number of hardware Tx buffers allocated to this queue. Any value but auto is NOT scaled by the number of ports, i.e., the value gets split on ports linked to the Tx Manager. When given in percent, it means percentage of the tx-manager's queue-buffers value.
use-shared-buffers (yes | no)Allow the queue to use the shared buffer pool when queue-buffersare full. If the queue is full and the shared buffers are disabled, the packet gets dropped. If the shared buffers are enabled, the queue may use up to shared-packet-cap or shared-poolX-packet-cap (see QoS Settings for details) packets from the shared pool.
wred(yes | no; Default: no)Enables/disables Weighted Random Early Detection for the given queue.
*****ecn (*****yes | no; Default: no)Enables/disables ECN marking of the transmitted packets.
wred-actual(yes | no; read-only)The actual WRED value.
ecn-actual (yes | no; read-only)The actual ECN value.
danger

On some device models, due to hardware limitations, enabling ECN on one queue turns on CE marking of ECN-capable packets on all queues. In such cases, ecn-actual=yes despite ecn=no.

Priority-based Flow Control (PFC)​

Sub-menu: /interface/ethernet/switch/qos/priority-flow-control

PFC configuration is organized in profiles. Different switch ports can be assigned to different PFC profiles. The maximum number of hardware Tx managers depends on the switch chip model. The builtin profile named "disabled" cannot be changed.

PropertyDescription
name (string; Default: )The user-defined name of the PFC profile
pause-threshold (percent: 0%..100% | bytes | auto; Default: auto)Transmits a pause frame (XOFF) when the total size of enqueued packets reaches this threshold. Enqueued packets are counted per ingress port. Applies only when tx=yes. The value can be given either explicitly in bytes or percent of the respective shared pool size (shared-poolX-byte-cap).
resume-threshold (percent: 0%..100% | bytes | auto; Default: auto)Transmits a resume frame (XON) when the total size of enqueued packets drops down to this threshold. Enqueued packets are counted per ingress port. Applies only when tx=yes. The value can be given either explicitly in bytes or percent of the respective shared pool size (shared-poolX-byte-cap).
rx (yes | no; Default: no)Enables receiving of PFC frames. The received PFC frame pauses the specific priority queues on the port that received the PFC frame for the duration specified by the PFC frame. Disabling rx disables queue pausing.
traffic-class (integer array: 0..7)The list of PFC-enabled traffic classes.
tx (yes | no; Default: no)Enables transmission of PFC frames.